The present invention relates generally to data communications networks and more particularly relates to a single sender private Selective Multicast Server (SMS) for use with LAN Emulation (LANE) in an Asynchronous Transfer Mode (ATM) network.
Currently, there is a growing trend to make Asynchronous Transfer Mode (ATM) networking technology the base of future global communications. ATM has already been adopted as a standard for broadband communications by the International Telecommunications Union (ITU) and by the ATM Forum, a networking industry consortium.
ATM originated as a telecommunication concept defined by the Comite Consulatif International Telegraphique et Telephonique (CCITT), now known as the ITU, and the American National Standards Institute (ANSI) for carrying user traffic on any User to Network Interface (UNI) and to facilitate multimedia networking between high speed devices at multi-megabit data rates. ATM is a method for transferring network traffic, including voice, video and data, at high speed. Using this connection oriented switched networking technology centered around a switch, a great number of virtual connections can be supported by multiple applications through the same physical connection. The switching technology enables bandwidth to be dedicated for each application, overcoming the problems that exist in a shared media networking technology, like Ethernet, Token Ring and Fiber Distributed Data Interface (FDDI). ATM allows different types of physical layer technology to share the same higher layerxe2x80x94the ATM layer.
ATM uses very short, fixed length packets called cells. The first five bytes, called the header, of each cell contain the information necessary to deliver the cell to its destination. The cell header also provides the network with the ability to implement congestion control and traffic management mechanisms. The fixed length cells offer smaller and more predictable switching delays as cell switching is less complex than variable length packet switching and can be accomplished in hardware for many cells in parallel. The cell format also allows for multi-protocol transmissions. Since ATM is protocol transparent, the various protocols can be transported at the same time. With ATM, phone, fax, video, data and other information can be transported simultaneously.
ATM is a connection oriented transport service. To access the ATM network, a station requests a virtual circuit between itself and other end stations, using the signaling protocol to the ATM switch. ATM provides the User Network Interface (UNI) which is typically used to interconnect an ATM user with an ATM switch that is managed as part of the same network.
The current standard solution for routing in a private ATM network is described in Private Network Node Interface (PNNI) Phase 0 and Phase 1 specifications published by the ATM Forum. The previous Phase 0 draft specification is referred to as Interim Inter-Switch Signaling Protocol (IISP). The goal of the PNNI specifications is to provide customers of ATM network equipment some level of multi-vendor interoperability.
Today, most data traffic in existing customer premises networks travels over legacy LANs. It is desirable to permit these legacy LANs and their embedded infrastructure to operate with new ATM networks currently being deployed. To enable an easier migration path to ATM, the ATM Forum has defined LAN Emulation (LANE) specification that allows ATM networks to coexist with legacy systems. The LANE specification defines a way for an ATM network to emulate a logical Ethernet or Token Ring segment, these currently being the most popular LAN technologies.
LANE service provides connectivity between ATM capable devices and legacy LAN capable devices across an ATM network. Since LANE connectivity is defined at the MAC layer, the upper protocol layer functions of LAN applications can continue to function unchanged after the device joins an emulated LAN. This important feature protects corporate investments in legacy LAN applications. An ATM network can support multiple independent emulated LAN (ELAN) networks. A network may have one or more emulated LANs wherein each emulated LAN is separate and distinct from the others. Emulated LANs communicate via routers and bridges just as they do in physical LANs. The emulated LAN provides communication of user data frames between its users just as in an actual physical LAN.
Emulation over ATM networks, the LANE Version 1.0 standard drafted by the ATM Forum and incorporated herein by reference, defines the LANE architecture and a set of protocols used by the LANE entities. LANE uses a client/server model to provide its services. A block diagram illustrating prior art Version 1.0 LAN Emulation services available to nodes in an ATM network is shown in FIG. 1. The network, generally reference 10, comprises an ATM network cloud (not shown) which includes a plurality of LECs 14 labeled LEC #1 through LEC #3 and a plurality of nodes 12 labeled node #1 through node #9 connected to LECs #1 through #3. The LECs are connected to a LAN Emulation services block 16 which comprises LECS 18, LES 20 and BUS 22.
The entities defined by the LANE architecture include LAN Emulation Clients (LECs) 14, a LAN Emulation Server (LES) 20, a Broadcast and Unknown Server (BUS) 22 and LAN Emulation Configuration Server (LECS) 18. The LES, BUS and LECS constitute what is referred to as the LANE Service (block 16).
Each LAN Emulation Client (LEC) represents a set of users, as identified by their MAC addresses. A LEC emulates a LAN interface that communicates with higher layer protocols such as IP, IPX, etc. that are used by these users. To achieve this task, the LEC communicates with the LANE Services and to other LECs. LECs communicate with each other and to the LANE Services via ATM Virtual Channel Connections (VCCs). The VCCs are typically Switched Virtual Circuits (SVCs), but Permanent Virtual Connections (PVCs) might also be used for this purpose.
In order for a LEC to participate in an emulated LAN, the LEC must first communicate with an LECS. It may utilize a specific ATM address of the LECS if it knows it, or, as is typically the case, may use the well known address of the LECS to establish communications.
As described previously, the LANE Service comprises several entities: LANE Server (LES), a Broadcast and Unknown Server (BUS) and LAN Emulation Configuration Server (LECS). The LES provides Joining, Address Registration and Address Resolution services to the LECs. Note that a given LES serves only a single emulated LAN.
The LANE BUS is responsible for the distribution of the Broadcast, Multicast and unknown traffic to the LECs that is typically sent by a LEC before the ATM address has been resolved. Note that a given BUS serves only one emulated LAN.
The LECS contains the database used in determining which emulated LAN a device belongs to. Each LEC consults the LECS once, at the time it joins an emulated LAN, to determine which emulated LAN it should join. The LECS assigns the LEC to a given emulated LAN by giving the LEC the ATM address of the LES associated with that particular emulated LAN. Different policies may be utilized by the LECS in making the assignment. The assignment may be based on the LECs physical location, i.e., ATM address, the LEC ID, i.e., the MAC address, or any other suitable criteria. Note that the LECS serves all the emulated LANs defined for the given administrative ATM network domain.
The straightforward implementation of the LANE Version 1.0 specification includes a single LECS for the entire administrative domain and a single LES per emulated LAN. A disadvantage of this implementation is that it suffers from a single point of failure for both the LECS and the LES. Failure of the LECS might take the entire network down while failure of the LES takes the entire emulated LAN down.
A block diagram illustrating the relationship between LEC, LECS, LES and BUS entities in prior art Version 1.0 LAN Emulation services is shown in FIG. 2. Two LECs 30 are shown in communication with each other in addition to an LECS 32, LES 34 and BUS 36. The protocol the LECs use to communicate with each other and to the LAN Emulation services is known as LAN Emulation User to Network Interface (LUNI). The scope of the LUNI is indicated by the dashed line 38.
A characteristic feature of these types of implementations, however, is that when a LES fails, all the LECs connected to it try to rejoin the emulated LAN by connecting to the LECS. The LECS, however, assigns these LECs to the same non operative LES. The connection fails and the process continues endlessly.
The LANE Version 2.0 draft specification addresses the single point of failure problem for the ELAN by defining a distributed architecture for the LANE services. Since the clients (LECs) should be effected by the particular implementation used to provide the services, the ATM Forum decided to split the LANE specification into two sub specifications: (1) LAN Emulation User to Network Interface (LUNI) and (2) LAN Emulation Network to Network Interface (LNNI).
The LUNI specification defines the interface between the LEC and the LANE Services and between the LEC and other LECs. The LNNI specification defines the interface between LANE Services entities, i.e., LECs, LESs, BUSs, etc. In addition, LNNI defines a new LAN Emulation Service entity, i.e., the Selective Multicast Server (SMS), to enhance the handling of Multicast traffic.
A block diagram illustrating the relationship between LEC, LECS, LES, BUS and SMS entities in prior art Version 2.0 LAN Emulation services is shown in FIG. 3. Two LECs 40 are shown in communication with each other and to either of two LECS 42, LES 44 and BUS 46. In addition, both LECs and the LECS, LES and BUS communicate with a Selective Multicast Server (SMS) entity 48. Note that there can be more than one SMS per ELAN.
Note that in connection with the LNNI scheme, there may be several LECSs defined per administrative ATM domain in addition to several active LESs defined per ELAN. Each LECS maintains the list of currently active LESs. In case a LES fails, a mechanism is defined to ensure that all the LECSs are notified of the failure in order that none of the LECS assign LECs to non operational LESs. All the LECs previously connected to the failed LES are re-assigned by the LECS to other active LESs.
In the draft Version 2.0 of the LANE standard, the services include having multiple LECSs with each LECS having multiple ELANs. The LECs (clients) are apportioned across the LESs. Redundancy is handled by defining several LESs for the same ELAN, i.e., LES #1, LES #2, etc. The prior art redundancy method is described in connection with FIG. 2 that illustrates a portion of an example prior art Emulated LAN having a plurality of LECSs, LECs and LESs. The Emulated LAN, generally referenced 30, comprises LECS 18 labeled LECS #1 and LECS #2, LESs 16 labeled LES #1 and LES #2, BUSs 20 and LECs 14 labeled LEC #1, LEC #2 and LEC #3.
As described above, in the LANE Version 1.0 architecture (see FIGS. 1 and 2), the BUS is responsible for handling three types of traffic: broadcast, multicast and unknown unicast. The multicast traffic is generated by one or more applications that send their data to a group of receivers. The group of receivers does not include all the clients of the ELAN. For example, these applications include but are not limited to video broadcasting, distribution of data information, e.g., software distribution or push technology, video conferencing, remote learning, etc.
It is expected that these applications will increase in popularity in the near future. Therefore, the amount of multicast traffic is expected to also increase to a large extent. If multicast traffic were to grow, based on the LANE Version 1.0 implementation, the BUS would quickly become a bottleneck for traffic when the total amount of multicast traffic on the ELAN exceeds the forwarding power of the BUS.
Note that it is expected that in the near future Multicast traffic will become very heavy in networks. Broadcast traffic occurs mainly in the startup phase of the network and network elements. Once operating, little continuous broadcast traffic is generated. Similarly, unknown traffic is also not generated on a continuous basis. Unknown traffic is generated, for example, by a network element before a direct connection is established between two network devices.
In addition, multicast traffic is currently handled as broadcast traffic. All multicast traffic defaults to the BUS (to the LES for unicast traffic). In other words, regardless of the size and membership of the multicast group, a multicast message is broadcast to all the LECs and all members attached to the LECs.
To summarize, the disadvantage of LANE Version 1.0 is (1) the lack of true multicast capability (multicast is treated as broadcast) and (2) the lack of redundancy (if a LES or BUS fails the entire ELAN goes down). In particular, multicast traffic is limited by the forwarding capability of the BUS and by the slowest downlink to a LEC. Further, in switched edge device, all multicast traffic is distributed to all the ports.
Since, however, up till now relatively little multicast traffic was generated, the redundancy problem was considered far more important. Today, however, and in the near future the increase in multicast traffic generated by applications which cause the first problem, i.e., lack of true multicast, to become an important problem as well.
The LNNI portion of LANE Version 2.0 addresses these issues by providing a means of offloading the multicast traffic from the BUS. With reference to FIG. 3, this is achieved by the addition of one or more Selective Multicast Servers (SMSs) 48 that are responsible for handling multicast traffic.
A standard prior art SMS is constructed to perform the following functions. SMSs are designed to forward traffic on a packet level as opposed to forwarding traffic on a cell level. SMSs utilize a heavy protocol known as Server Cache Synchronization Protocol (SCSP). In LNNI most of the information between entities, i.e., LES, SMS, LECS, is transferred using this protocol. This protocol is needed to enable the SMS and LES to reside on different network devices. In addition, SMSs introduce themselves to the LECS and after obtaining the LES(s) from the LECS. After this first introduction they introduce themselves again to the LES(s) themselves. Further, SMSs must forward multicast traffic to the BUS to insure backward compatibility with non-SMS enabled LECs.
A block diagram illustrating the SAR of cells to and from packets in a prior art SMS system is shown in FIG. 4. The SMS, generally referenced 50, comprises, among other things, a segmentation and reassembly (SAR) unit 52. As described above, a major function (of the SMS is to receive and distribute multicast traffic. The SMS offloads this burden from the BUS that currently handles multicast traffic as broadcast traffic.
In operation, one or more LECs establish connections to the SMS 50. Cells 58 forwarded to the SMS from one or more LECs are received and input to the SAR 52. A reassembly unit 54 functions to reassemble the cells into packets 60. The cells are not forwarded until all cells comprising a packet are received. The SMS cannot multiplex different multicast traffic streams on the cell level, thus the requirement for an SAR in prior art SMS. It can, however, multiplex on the packet level.
Once all cells making up a packet have arrived, the packet is then segmented into cells 62 and distributed to each receiver, i.e., member, in the particular multicast group associated with the packet.
For traditional LAN traffic, AAL5 is the means used by which Ethernet and Token Ring frames are encapsulated into ATM cells. AAL5, however, does not provide any multiplexing capabilities. This means that cells derived from a particular frame are queued until all have arrived at the SAR before the packet is passed to the segmentation unit and transmitted as cells to the plurality of multicast destinations, i.e., receivers.
Note that in practice, the SMS may be implemented in various devices but typically, it is implemented in ATM switches. More than one SMS may reside in a network with each SMS residing on a different switch. The SMSs communicate with LESs via the SCSP protocol.
Initially, the LEC requests the LES for a destination for sending multicast traffic. The LES responds with the address of an SMS. The SMS maintains a list of Multicast Media Access Control (MMAC) addresses, wherein each MMAC represents a multicast group. It is possible that several SMSs serve the same MMAC so as to provide load balancing in the event the output demand exceeds any one SMS.
The LESs have knowledge of the locations of the SMSs and the MMACs handled by each. When an LE_ARP_REQ message arrives at a LES from a LEC for a particular MMAC, the LES replies with the ATM address of the LES. If the LES does know about any SMSs, it sends the LEC the ATM address of the BUS. Thus, the BUS is the default in the event an SMS cannot be assigned.
In a network with multicast, the sending and receiving functions are independent of each other. In other words multicast connections may involve overlapping LECs or they may involve totally non overlapping LECs. The same LEC may function as a sender and a receiver for a single multicast connection or for multiple multicast connections.
Once the LEC obtains the ATM address of the SMS, it establishes a point to point connection to the SMS. The LEC then sends multicast traffic to the SMS over that connection (referenced 58), as illustrated in the example shown in FIG. 4.
For listening, the LEC issues an LE_REGISTER_REQ message for a particular MMAC and sends it to the LES. The LES, using the LNNI SCSP protocol, instructs the SMS to add the LEC to the point to multipoint connection.
A disadvantage of the above scheme is that the SMS is required to perform reassembly and segmentation of the cells into packets and back into cells. The SMS performs packet switching that involves the use of a combination of software and hardware. The need to process the packets using software creates a large potential bottleneck and a limitation on the forwarding capabilities of the SMS.
A further disadvantage is that the current prior art scheme is not scalable as three types of traffic, i.e., broadcast, multicast and unknown, are handled by a single entity. In addition, each LEC receives all the multicast traffic resulting in very inefficient utilization of bandwidth and the wasting of CPU resources on the end station due to the required software filtering of the MMACs.
The present invention solves the problems associated with the prior art by providing a system comprising a single sender SMS that collocates the SMS, used for forwarding multicast traffic, in the same device as the LEC. Thus, the LEC has associated with it a private SMS for exclusive use by it alone. This is in contrast to the prior art scheme of requiring multicast traffic to be sent first from the LEC entity to the SMS (located somewhere else in the network) and then having the SMS forward the multicast traffic to the receiving destinations. This prior art scheme required cells to be first reassembled into packets, processed by the SMS at the packet level and forwarded to the listener LECs after segmentation back into cells.
In contrast, the SMS of the present invention enables a LEC to distribute multicast traffic in the most efficient way possible. The multicast traffic is not sent from the sending LEC to the SMS over the network. Rather, the LEC communicates with the SMS directly via the operating system internal messaging subsystem or equivalent. Using the apparatus and method of the present invention, the multicast traffic is sent on a point-to-multipoint connection from the sending LEC via the SMS to all the receiving LECs interested in listening to a given MMAC. The interface between the local LEC and the collocated SMS utilizes a communications protocol that may or may not be standard. Any suitable communication means known in the art is suitable for use with the invention. The communication protocol chosen for use between the local LEC and the collocated SMS does not, however, effect other LECs that function as listeners. These LECs continue to utilize the standard LUNI protocol.
Collocating the LEC with the SMS provides for a much smaller delay of multicast traffic from sender to receivers. The magnitude of the reduction in the latency and throughout delay is equal to the time previously taken to transmit the cells from the LEC to the SMS, reassemble the packet and segment it back into cells as performed by prior art SMS devices.
A key feature of the present invention is the creation of an optimal path between the sending LEC and the receiving LECs. This is achieved by collocating the SMS in the same device, e.g., edge device, as the LEC. The LES, however, is located in a device typically separate from the device incorporating the LEC/SMS. The mechanism of the present invention enables a LES to assign a LEC exclusively to its private SMS while not permitting the assignment of any additional LECs to that SMS. Two alternative embodiments are disclosed that function to implement this mechanism.
In the first embodiment, the LEC internally has knowledge of the existence of the private SMS and is inhibited from issuing a LE_ARP_REQ to find the SMS. An entry is added to the database in the LES with an attribute of xe2x80x98NOT_ASSIGNABLExe2x80x99 that effectively prevents the LES from assigning an LEC to that SMS.
In the second embodiment, address and LEC information is predefined for the SMS and propagated to all the SMSs. An entry is added to the database in the LES with an attribute of xe2x80x98ASSIGNABLE_LECxe2x80x99 along with an associated ATM address of the one and only one LEC that the LES is permitted to assign to the SMS. This effectively prevents the LES from assigning a LEC other than the registered LEC to that SMS.
Advantages of the present invention include but are not limited to: (1) the creation of an optimal distribution path from the SMS to all the listener LECs (the path being optimal in the sense that for a given routing protocol, e.g., PNNI, etc., a more efficient path cannot be found); (2) configuration of the system is simpler as the SMS is collocated with the LEC thus eliminating the requirement of heavy communication protocols and associated links between SMS and LEC (the LEC can be configured with a private SMS); (3) the use of cell switching for the distribution of multicast traffic versus packet switching thus reducing the transmission delay; and (4) LANE Version 1.0 LECs and LANE Version 2.0 SMS LECs do not receive multicast traffic offloading the BUS and eliminating it as the bottleneck.
There is therefore provided in accordance with the present invention, in an Asynchronous Transfer Mode (ATM) network including LAN Emulation services capabilities, the LAN Emulation services including LAN Emulation Server (LES), LAN Emulation Configuration Server (LECS), a method of providing a private Selective Multicast Server (SMS), the method comprising the steps of collocating the private SMS with a sending LAN Emulation Client (LEC) in a network device, the sending LEC receiving a request to send multicast traffic to a Multicast Media Access Control (MMAC) received from a sending end station, the LES assigning the private SMS exclusively to the sending LEC such that no other LECs are assigned to the private SMS, the SMS establishing a point-to-multipoint connection to all listening LECs registered to receive from the MMAC and forwarding multicast traffic to the listening LECs via the point-to-multipoint connection.
The method further comprises the steps of initializing the SMS such that an entry is added to an associated SMS database having an attribute of xe2x80x98NOT_ASSIGNABLExe2x80x99, synchronizing the SMS database with a LES database associated with the LES, preventing the LES from assigning LECs other than the sending LEC to the SMS and the LEC learning of the existence of the private SMS via means internal to the network device.
The method further comprises the steps of initializing the SMS such that an entry is added to an associated SMS database having an attribute of xe2x80x98ASSIGNABLE_LECxe2x80x99 and comprising the ATM address of the sending LEC, the sending LEC being the sole LEC permitted to be assigned as a sender to the private SMS, synchronizing the SMS database with a LES database associated with the LES, the sending LEC issuing a LE_ARP_REQ to the LES for a particular MMAC, searching in a LES database for an entry indicating that there is a private SMS serving the sending LEC and the LES sending a LE_ARP_RES to the sending LEC with an indication to the sending LEC that the private SMS is collocated with the sending LEC.
The method further comprises the step of a receiving LEC requesting to receive from a MMAC comprising the steps of the LES receiving a LE_REGISTER_REQ message from the receiving LEC, the LES updating a LES database and issuing a LE_BREGISTER_RES to the receiving LEC, updating all SMS databases with changes made to the LES database and the SMS adding the receiving LEC requesting to listen to a MMAC as a leaf in its point-to-multipoint connection for that MMAC.
The method further comprises the step of stopping sending multicast traffic to a MMAC comprising the steps of the sending LEC indicating to the private SMS that it wishes to stop sending to a given MMAC and the SMS removing the point-to-multipoint data path.
The method further comprises the step of stopping listening to a MMAC comprising the steps of the LES receiving a LE_UNREGSITER_REQ from a receiving LEC, the LES updating a LES database and issuing a LE_UNREGISTER_RES to the receiving LEC, updating all SMS databases with changes made to the LES database and the SMS removing the receiving LEC from a corresponding point-to-multipoint connection for a particular MMAC.